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METHOD AND APPARATUS FOR DYNAMIC 
CONFIGURATION OF MULTIPROCESSOR SYSTEM 



BACKGROUND 



Cars include many different electro-mechanical and electronic applications. 
Examples include braking systems, electronic security systems, radios, Compact Disc (CD) 
players, internal and external lighting systems, temperature control systems, locking systems, 
seat adjustment systems, speed control systems, mirror adjustment systems, directional 
indicators, etc. Generally the processors that control these different car systems do not talk to 
each other. For example, the car radio does not communicate with the car heating system or 
the car braking system. This means that each one of these car systems operate independently 
and do not talk to the other car systems. For example, separate processors and separate user 
interfaces are required for the car temperature control system and for the car audio system. 
Many of these different car processors may be underutilized since they are only used 
intermittently. 

Even when multiple processors in the car do talk to each other, they are usually so "i 

tightly coupled together that it is impossible to change any one of these processors without 
disrupting all of the systems that are linked together. For example, some cars may have a 
dashboard interface that controls both internal car temperature and a car radio. The car radio 
cannot be replaced with a different model and still work with the dashboard interface and the 
car temperature controller. 

Integration of new systems into a car is also limited. Car systems are designed and 
selected well before the car is ever built. A custom wiring harness is then designed to 
connect only those car systems selected for the car. A car owner cannot incorporate new 
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systems into the existing car. For example, a car may not originally come with a navigation 
system. An after market navigation system from another manufacturer cannot be integrated ^ 
into the existing car. 

Because after market devices can not be integrated into car control and interface 
systems, it is often difficult for the driver to try and operate these after market devices. For 
example, the car driver has to operate the after market navigation system from a completely 
new interface, such as the keyboard and screen of a laptop computer. The driver then has to 
operate the laptop computer not from the front dashboard of the car, but from the passenger 
seat of the car. This makes many after market devices both difficult and dangerous to operate 
while driving. 

The present invention addresses this and other problems associated with the prior art. 

SUMMARY OF THE INVENTION 
A multiprocessor system used in a car, home, or office environment includes multiple 
processors that run different real-time applications. A dynamic configuration system runs on 
the multiple processors and includes a device manager, configuration manager, and data 
manager. The device manager automatical^^ and adds new devices to the 
multiprocessor system, and the configuration manager automatically reconfigures which 
processors run the real-time applications. The data manager identifies the type of data 
generated by the new devices and identifies which devices in the multiprocessor system are 
able to process the data. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a diagram of a car that has multiple processors that each run a Dynamic 
Configuration (DC) system. 
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FIG. 2 is a detailed diagram of the dynamic configuration system shown in FIG. 1. 
FIGS. 3 and 4 are diagrams showing an example of how the DC system operates. 
FIGS. 5 and 6 are diagrams showing how a device manager in the DC system 
operates. 

FIGS. 7-10 are diagrams showing how a reconfiguration manager in the DC system 
operates. 

FIGS. 1 1 and 12 are diagrams showing how a data manager in the DC system 
operates. 

FIG. 13 is a diagram showing different multiprocessor systems that can use the DC 
DC system. 

DETAILED DESCRIPTION 
FIG. 1 shows a car 12 that includes a car multiprocessor system 8 having multiple 
processors 14, 16, 18 and 20. An engine monitor processor 14 monitors data from different 
sensors 22 and 24 in the car engine. The sensors 22 and 24 can be any sensing device such as 
sensors that monitor water temperature, oil temperature, fiiel consumption, car speed, etc. A 
brake control processor 20 monitors and controls an Automatic Braking System (ABS) 28. A 
display processor 16 is used to control and monitor a graphical user interface 26. A security 
processor 18 monitors and controls latches and sensors 30 and 32 that are used in a car 
security system. 

The processors 14, 16, 18 and 20 all include software that run a Dynamic 
Configuration (DC) system 10 that enables new processors or devices to be automatically 
added and removed from the car multiprocessor system 8. The DC system 10 also 
automatically reconfigures the applications running on different processors according to 
application failures and other system processing requirements. 
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For example, the processor 20 may currently be running a high priority brake control 
application. If the processor 20 fails, the DC system 10 can automatically download the 
braking application to another processor in car 12. The DC system 10 automatically 
identifies another processor with capacity to run the braking control application currently 
running in processor 20. The DC system 10 then automatically downloads a copy of the 
braking control application to the identified processor. If there is no extra reserve processing 
resources available, the DC system 10 may replace a non-critical application running on 
another processor. For example, the DC system 10 may cause the display processor 16 to 
terminate a current non-critical application and then download the brake control application 
along with any stored critical data. 

The DC system 10 also automatically incorporates new processors or applications into 
the multiprocessor system 8. For example, a laptop computer 38 can communicate with the 
engine.monitor processor 34 through a hardwired link 34 or communicate to the display 
processor 16 through a wireless link 36. The DC system 10 automatically integrates the 
laptop computer 38, or any other processor or device, into the multiprocessor system 8. After 
integrated into the multiprocessor system 8, not only can the laptop computer 38 transfer data 
with other processors, but the laptop computer may also run car applications normally run by 
other processors in car 12. 

The DC system 10 allows the car driver to manage how different applications are 
processed in the car 12. As described above, a car operator may have to run an aftermarket 
navigation system through a GPS transceiver attached to the laptop computer 38. The car 
driver has to place the laptop computer 38 in the passengers seat and then operate the laptop 
computer 38 while driving. 

The DC system 10 in the display computer 16 can automatically detect the navigation 
application running on the laptop computer 38. The display computer 16 notifies the car 
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operator through the user interface 26 that the navigation appHcation has been detected. The 
car operator can then control the navigation application through the user interface 26. Since 
the user interface 26 is located in the dashboard of car 12, the car operator no longer has to 
take his eyes off the road while operating the navigation application. 

The description below gives only a few examples of the different processors, devices 
and applications that can be implemented using the DC system 10. Any single or 
multiprocessor system located either inside or outside of car 12 can communicate and 
exchange data using the OC system 10. It should also be understood that the DC system 10 
can be used in any real-time environment such as between processors in different home or 
office appliances and different home and office computers. 

FIG. 2 is a block diagram showing in more detail the Dynamic Control (DC) system 
10 located in a processor 40 that makes up part of the multiprocessor system 8 in car 12 (FIG. 
1). The DC system 10 includes a device manager 46 that establishes communications with 
new devices that are to be incorporated into the multiprocessor system 8. A configuration 
manager 44 in the processor 40 dynamically moves applications between different processors 
according to user inputs and other monitored conditions in the multiprocessor system 8. A 
data manager 42 identifies a type of data input or output by a new processor and identifies 
other processors or devices in the multiprocessor system that can output data from the new 
device or input data to the new device. 

In one example, sensors 52 feed sensor data to processor 40. The sensor data may 
include engine-monitoring data such as speed, oil temperature, water temperature, 
temperature inside the car cab, door open/shut conditions, etc. The sensors 52 are coupled to 
processor 40 through a link 54, such as a proprietary bus. A Compact Disc (CD) player 50 is 
coupled to the processor 40 through another link 48, such as a Universal Serial Bus (USB). 
Graphical User Interface (GUI) 56 displays the data associated with sensors 52 and CD 
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player 50. The GUI 56 displays the outputs from sensors 52 using an icon 60 to identify 
temperature data and an icon 62 to identify car speed. The processor displays the CD player 
50 as icon 62. 

FIGS. 3 and 4 show an example of how two new applications are dynamically added 
to the multiprocessor system 8 in car 12 (FIG. 1). In FIG. 2, the DC system 10 in processor 
40 previously detected a CD player 50 and some sensors 56. The CD player 50 was 
displayed on GUI 56 as icon 58 and the temperature and speed data from sensors 56 were 
displayed on GUI 56 as icons 60 and 62, respectfully. 

The processor 40 is located in car 12 (FIG. 1). A passenger may bring a Digital 
Video Disc (DVD) player 86 into the car 12. The DVD 86 sends out a wireless or wired 
signal 88 to the processor 40. For example, the DVD 86 may send out signals using a IEEE 
802.1 1 wireless protocol. The processor 40 includes an IEEE 802.1 1 interface that reads the 
signals 88 from DVD player 86. If the 802.1 1 protocol is identified as one of the protocols 
used by processor 40, the DC system 1 0 incorporates the DVD player 86 into a processor 
array 57 that lists different recognized applications. 

The DC system 10 then automatically displays the newly detected DVD player 86 on 
GUI 56 as icon 96. If capable, the car operator by selecting the icon 96 can then display a 
video stream output from the DVD player 86 over GUI 56. The DVD player 86 can now be 
controlled from the GUI 56 on the car dashboard. This prevents the car driver from having to 
divert his eyes from the road while trying to operate the portable DVD player 86 from 
another location in the car, such as from the passenger seat. 

Other processors or devices can also be incorporated into the multiprocessor system 8 
in car 12. In another example, the car 12 drives up to a drive-in restaurant 90. The drive-in 
90 includes a transmitter 92 that sends out a wireless Blue tooth signal 94. The processor 40 
includes a Blue tooth transceiver that allows communication with transmitter 92. The DC 
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system 10 recognizes the signals 94 from transmitter 92 and then incorporates the drive-in 90 
into the multiprocessor system 8 (FIG. 1). The DC system 10 then displays the drive-in 90 as 
icon 98 in GUI 56. 

Referring to FIG. 4, when the car operator selects the icon 98, a menu 102 for the 
driver-in 90 is displayed on the GUI 56. The car operator can then select any of the items 
displayed on the electronic menu 102. The selections made by the car operator are sent back 
to the transceiver 92 (FIG. 3). The amount of the order is calculated and sent back to the 
processor 40 and displayed on menu 102. Other messages, such as a direction for the car 
operator to move to the next window and pickup the order can also be displayed on the GUI 
56. At the same time, the drive-in transceiver 92 (FIG. 3) may send audio signals that are 
received by the processor 40 and played out over speakers in car 12. 

FIG. 5 shows in more detail the operation of the device manager 46 previously shown 
in FIG. 2. Multiple processors A, B, C and D all include device managers 46. The device 
managers 46 can each identify other devices in the multiprocessor system that it 
communicates with. For example, processors A, B, C and D communicate to each other over 
one or more communication links including a Ethernet link 64, a wireless 802.1 1 link 68, or a 
blue tooth link 70. 

Processor A includes a memory 65 that stores the other recognized processors B, C 
and D. The data managers 46 also identify any applications that may be running on the 
identified processors. For example, memory 65 for processor A identifies an application #2 
running on processor B, no applications running on processor C, and an application #4 
running on processor D. 

FIGS. 5 and 6 show how a new device is added to the multiprocessor system 8. Each 
of the existing processors A, B, C, and D after power-up are configured to identify a set or 
subset of the processors in the multiprocessor system 8. A new device 72 is brought into the 
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multiprocessor system 8 either via a hardwired link or a wireless link. For example, the 
device E may send out signals over any one or more of a 802.1 1 wireless link 67, Blue tooth 
wireless link 71 or send out signals over a hardwired Ethernet link 69. Depending on what 
communication protocol is used to send signals, one or more of the processors A, B, C or D 
using a similar communication protocol detect the processor E in block 74 (FIG. 6). All of 
the processors may be connected to the same fiber optic or packet switched network that is 
then used to communicate the information from processor E to the other processors. 

One of the device managers 46 in the multiprocessor system 8 checks the signals from 
processor E checks to determine if the signals are encrypted in a recognizable protocol in 
block 76. The device manager in the processor receiving the signals from processor E then 
checks for any data codes from the new device signals in block 76. The data codes identify 
data types used in one or more applications by processor E. A device ID for processor E is 
then determined from the output signals in block 80. 

If all these data parameters are verified, the device managers 46 in one or more of the 
processors A, B, C and D add the new processor E to their processor arrays in block 82. For 
example, processor A adds processor E to the processor array in memory 65. After being 
incorporated into the multiprocessor system 8, the processor E or the applications running on 
the processor E may be displayed on a graphical user interface in block 84. 

FIG. 7 describes in fiirther detail the operation of the reconfiguration manager 44 
previously described in FIG. 2. In the car multiprocessor system 8 there are four processors 
A, B, C and D. Of course there may be more than four processors running at the same time 
in the car but only four are shown in FIG. 7 for illustrative purposes. The processor A 
currently is operating a navigation application 1 10 that uses a Global Positioning System 
(GPS) to identify car location. Processor B currently runs an audio application 1 12 that 
controls a car radio and CD player. The processor C runs a car Automatic Braking System 
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(ABS) application 1 14 and the processor D runs a display application 1 16 that outputs 
information to the car operator through a GUI 118. 

The processor D displays an icon 120 on GUI 118 that represents the navigation 
system 110 running in processor A. An icon 124 represents the audio application running in 
processor B and an icon 122 represents the ABS application 1 14 running in processor C. 

The memory 128 stores copies of the navigation application 110, audio application 
1 12, ABS application 1 14 and display application 1 16. The memory 128 can also store data 
associated v/\ih the different applications. For example, navigation data 130 and audio data 
132 are also stored in memory 128. The navigation data 130 may consist of the last several 
minutes of tracking data obtained by the navigation application 110. The audio data 132 may 
include the latest audio tracks played by the audio application 1 12. 

The memory 128 can be any CD, hard disk, Read Only Memory (ROM), Dynamic 
Random Access (RAM) memory, etc. or any combination of different memory devices. The 
memory 128 can include a central memory that all or some of the processors can access and 
may also include different local memories that are accessed locally by specific processors. 

FIG. 8 shows one example of how the configuration manager 44 reconfigures the 
multiprocessor system when a failure occurs in a critical application, such as a failure of the 
ABS application 1 14. The configuration manager 44 for one of the processors in the 
multiprocessor system 8 detects a critical application failure in block 134. 

One or more of the configuration managers 44 include a watchdog function that both 
monitors its own applications and the applications running on other processors. If an intemal 
application fails, the configuration manager may store critical data for the failed application. 
The data for each application if stored in the memory 128 can selectively be encrypted so that 
only the car operator has the authority to download certain types of data. 
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The configuration manager detecting the failure initiates a reboot operation for that particular 
application. The application is downloaded again from memory 128 and, if applicable, any 
stored application data. If the application continues to lockup, the configuration manager 
may then initiate a reconfiguration sequence that moves the application to another processor. 

Failures are identified by the watchdog functions in one example by periodically 
sending out heartbeat signals to the other processors. If the heartbeat from one of the 
processors is not detected for one of the processors, the configuration manager 44 for the 
processor that monitors that heartbeat attempts to communicate with the processor or 
application. If the application or processor with no heartbeat does not respond, the 
reconfiguration process is initiated. 

In another example, certain processors may monitor different applications. For 
example, a sensor processor may constantly monitor the car speed when the car operator 
presses the brake pedal. If the car speed does not slow down when the brake is applied, the 
sensor processor may check for a failure in either the braking application or the speed sensing 
application. If a failure is detected, the configuration manager initiates the reconfiguration 
routine. 

When reconfiguration is required, one of the reconfiguration managers 44 first tries 
to identify a processor that has extra processing capacity to run the failed application in block 
136. For example, there may be a backup processor in the multiprocessor system where the 
ABS application 1 14 can be downloaded. If extra processing resources are available, the 
ABS application 1 14 is downloaded from the memory 128 (FIG. 7) to the backup processor 
in block 142. 

There may also be data associated with the failed application that is stored in memory 
128. For example, the brake commands for the ABS application 1 14 may have been 
previously identified for logging in memory 128 using a logging label described in 
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co-pending application entitled: OPEN COMMUNICATION SYSTEM FOR REAL-TIME 

MULTIPROCESSOR APPLICATIONS, serial no. filed which is 

herein incorporated by reference. The logged brake commands are downloaded to the backup 
processor in block 142. 

If no backup processing resources can be identified in block 136, the configuration 
manager 44 identifies one of the processors in the multiprocessor system that is running a 
non-critical application. For example, the configuration manager 44 may identify the 
navigation application 1 10 in processor A as a non-critical application. The configuration 
manager 44 in block 140 automatically replaces the non-crifical navigafion application 1 10 in 
processor A with the critical ABS application 1 14 in memory 128. The processor A then 
starts running the ABS application 1 14. 

FIGS. 9 and 10 show an example of how the configuration manager 44 allows the 
user to control reconfiguration for non-critical applications. The applications currently 
running in the muhiprocessor system 8 are displayed in the GUI 1 18 in block 150. A failure 
is detected for the navigation application 1 10 running in processor A in block 152. The 
configuration manager 44 in processor A, or in one of the other processors B, C, or D detects 
the navigation failure. Alternatively, a fiision processor 1 1 1 is coupled to some or all of the 
processors A, B, C and D and detects the navigation failure. 

In block 154 the configuration manager 44 for one of the processors determines if 
there is extra capacity in one of the other processors for running the failed navigation 
application 110. If there is another processor with extra processing capacity, the navigation 
application is downloaded fi^om memory 128 to that processor with extra capacity along with 
any necessary navigation data in block 156. This reconfiguration may be done automatically 
without any interaction with the car operator. 
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If there is no extra processing capacity for running the navigation appUcation 1 10, the 
configuration manager 44 displays the failed processor or application to the user in block 
158. For example, the GUI 1 18 in FIG. 9 starts blinking the navigation icon 120 in possibly a 
different color than the audio application icon 124. A textual failure message 125 can also be 
displayed on GUI 118. 

The configuration manager in block 160 waits for the car operator to request 
reconfiguration of the failed navigation application to another processor. If there is no user 
request, the configuration managers return to monitoring for other failures. If the user 
requests reconfiguration, the configuration manager 44 in block 164 displays other non- 
critical applications to the user. For example, the GUI 118 only displays the audio 
application icon 124 in processor B and not the ABS application icon 122 (FIG. 7). This is 
because the audio application is a non-critical application and the ABS application 1 14 is a 
critical application that cannot be cancelled. 

If the car operator selects the audio icon 124 in block 166, the configuration manager 
in block 168 cancels the audio application 1 12 in processor B and downloads the navigation 
application 110 from memory 128 into processor B. A logging manager in processor A may 
have labeled certain navigation data for logging. That navigation data 130 may include the 
last few minutes of position data for the car while the navigation application 1 10 was running 
in processor A. The logged navigation data 130 is downloaded fi-om memory 128 along with 
the navigation application 110 into processor B. The navigation icon 120 in GUI 118 then 
shows the navigation application 110 running on processor B. At the same time the audio 
application icon 124 is removed from GUI 118. 

Referring back to FIG. 2, a processor or application is accepted into the 
multiprocessor system by one or more of the device managers 46. The configuration 
managers 44 in the processors reconfigure the multiprocessor system to incorporate the 
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processor or application. The data manager 42 then detects what type of data is transmitted 
or received by the new device and determines the different processors and input/output 
devices in the multiprocessor system that can receive or transmit data to the new application 
or processor. 

FIG. 1 1 shows in further detail how the data manager 42 in FIG. 2 operates. In block 
170, the data manager for one of the processors determines the data standard for the data that 
is either transmitted or received by a new device. For example, the new device may be a 
MPS player that outputs streaming audio data. In another example, the new device may be a 
DVD player that outputs streaming video data in a MPEG format. 

One or more of the data managers 42, identifies the device by its data and the data, if 
applicable, is displayed on the graphical user interface in block 172. The data manager then 
identifies any devices in the muhiprocessor system that can output or transmit data to the new 
device in block 174. For example, a newly detected audio source may be output from a car 
speaker. The data manager monitors for any user selections in block 176. For example, the 
car operator may select the output from a portable CD player to be output from the car 
speakers. The data manager controlling the CD player and the data manager controlling the 
car speakers then direct the output from the CD player to the car speakers in block 178. 

FIG. 12 gives one example of how the data managers 42 in the multiprocessing 
system operate. A GUI 1 80 displays the audio or video (AAO sources in a car. For example, 
there are three devices detected in or around the car that are AA^ sources. A cellular 
telephone detected in the car is represented by icon 184, a radio is represented by icon 186, 
and a DVD player is represented by icon 188. 

The AA^ output devices in the car are shown in the lower portion of GUI 180. For 
example, icons 192, 194, 196, 200, and 204 show car audio speakers. An in-dash video 
display is represented by icon 190 and a portable monitor is represented by icon 198. 
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Currently, a car operator may be listening to the radio 186 over speakers 192, 194, 
196, 200 and 204. However, a passenger may move into the backseat of the car carrying an 
MPS player. The MP3 player runs the DC system 10 described in FIG. 2 and sends out a 
signal to any other processors in the multiprocessor system 8 in the car. The device manager 
46 and configuration manager 44 in one of the processors verify the data format for the MPS 
player and configure the MPS player into the multiprocessor system. 

One of the data managers 42 determines the MPS player outputs a MPS audio stream 
and accordingly generates the icon 182 on the GUI 180. The data manager 42 also identifies 
a speaker in the MPS player as a new output source and displays the speaker as icon 202. 
The car operator sees the MPS icon 182 now displayed on GUI 180. The car operator can 
move the MPS icon 182 over any combination of the speaker icons 192, 194, 196, 200 and 
204. The output from the MPS player is then connected to the selected audio outputs. 

Audio data can also be moved in the opposite direction. The speaker icon 202 
represents the output of the portable MPS player that the passenger brought into the backseat 
of the car. The car operator also has the option of moving one or more of the other audio 
sources, such as the cellular telephone 1 84 or the radio 1 86 icons over the speaker icon 202. 
If the car operator, for example, moves the radio icon 186 over the MPS player speaker icon 
202 and the MPS player can output the radio signals, the multiprocessor system redirects the 
radio broadcast out over the MPS speaker. 

It should be understood that the multiprocessor system described above could be used 
in applications other than cars. For example, FIG. IS shows a first GUI 210 that shows 
different processors and applications that are coupled together using the DC system 10 in an 
automobile. A GUI 212 shows another multiprocessor system comprising multiple 
processors in the home. For example, a washing machine is shown by icon 214. The DC 
system allows the washing machine processor to communicate and be configured with a 



Patent Application 
Atty. Doc. No. 9032-5 



14 



• # 

television processor 216, toaster processor 218, stereo processor 220, and an oven processor 
222. 

The system described above can use dedicated processor systems, micro controllers, 
programmable logic devices, or microprocessors that perform some or all of the 
communication operations. Some of the operations described above may be implemented in 
software and other operations may be implemented in hardware. 

For the sake of convenience, the operations are described as various interconnected 
functional blocks or distinct software modules. This is not necessary, however, and there 
may be cases where these fimctional blocks or modules are equivalently aggregated into a 
single logic device, program or operation with unclear boundaries. In any event, the 
fiinctional blocks and software modules or described features can be implemented by 
themselves, or in combination with other operations in either hardware or software. 

Having described and illustrated the principles of the invention in a preferred 
embodiment thereof, it should be apparent that the invention may be modified in arrangement 
and detail without departing from such principles. Claim is made to all modifications and 
variation coming within the spirit and scope of the following claims. 
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